-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs(api): get openapi files from dependencies repository #1402
docs(api): get openapi files from dependencies repository #1402
Conversation
@@ -77,3 +77,34 @@ dependencies { | |||
runtimeOnly(libs.edc.controlplane.callback.dispatcher.http) | |||
|
|||
} | |||
|
|||
tasks.register("downloadOpenapi") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should probably be in the root build file, because the dataplane also has an API and thus openAPI files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking, do we need to list the dataplane api as well? Because those should be considered internal ones, same as "control" and "dsp", that's why I'm working to filter them out (update to PR will come up soon).
likely to external viewers only "management" and "observability" would be interesting, wdyt?
otherwise a possibility could be to publish them separately as we're doing on upstream
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well... I would not necessarily consider the dataplane signaling API external. And then there is the token-refresh API in Tractus-X, that is not part of the DPS, but I would still consider public. Thinking of third-party dataplanes, etc.
We can obviously do this in another iteration, but dataplane APIs should still be documented I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not "external", but "internal".
token refresh is already part of the merged spec because it's not downloaded from maven repo but generated by the resolve
task.
anyway I will add the task for both control-plane and data-plane, for management-api
, observability-api
and public-api
, then let's wait for some feedback
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, i meant to say that I would not consider them internal ofc.
token refresh is already part of the merged spec because it's not downloaded from maven repo but generated by the resolve task.
i know, my point was that the dataplane very much has APIs that are public, such as DPS and token refresh. especially with DPS i see no reason not to include it.
f79b670
to
bff74f5
Compare
b6f823e
to
a14e347
Compare
a14e347
to
14fc7d3
Compare
WHAT
Add a gradle task that downloads all the openapi specs of the dependencies and use them to build the merged spec to be uploaded to swaggerhub
WHY
documentation
FURTHER NOTES
Part of #1393